1. Field of the Invention
The present invention relates to a digital rights management (DRM), and particularly, to domain upgrade method in DRM.
2. Background of the Invention
In general, a Digital Rights Management (DRM) is technique to protect a rights object (RO) for digital contents and systematically manage it, and provides a protecting and managing scheme for preventing an illegal copy of the contents, obtaining the RO, creating/moving the contents, and consuming the RO and the contents.
A DRM system includes a Contents Issuer (CI) and a Rights Issuer (RI). The DRM system controls a user to consume contents issued by the CI only in a right-limit of RO provided from the RI.
More concretely, the CI issues contents protected by a specific encryption key against an unauthorized user. And, the RI issues an RO necessary to consume the protected contents.
A DRM agent is mounted at a device (or terminal) thus to receive the protected contents and ROs, and controls consumption of the DRM contents by analyzing a ‘License’ contained in the RO, and by converting the protected DRM contents to contents that can be consumed at a corresponding DRM device.
Here, the device indicates a device including a DRM Agent, which is a domain member that has joined a domain.
In the DRM system, based on a newly introduced domain concept, devices inside a specific domain allow to share an RO with other devices. For instance, if a device, ‘A’ has an RO for consuming contents, the RO is shared with a plurality of devices for consumption.
Here, devices that belong to the domain (i.e., joined devices) are called as ‘domain members’, and each domain member shares a common domain key (DK).
The domain key is used to decode a domain RO. Here, the domain RO is an RO shared among devices inside the domain, and includes an RO and state information issued from the RI.
Details about the domain are described in standardized documents by Open Mobile Alliance, a group for application software standardization of a mobile device.
FIG. 1 is an exemplary view showing a domain in accordance with the conventional art, and FIG. 2 is a flowchart showing a DRM system of FIG. 1 in accordance with the conventional art.
As shown in FIG. 1, a domain 20 includes a plurality of members, i.e., first to fourth devices (11˜14, will be referred to as a representative reference numeral ‘10’) that share contents.
And, an entity for managing the domain 20 includes a Contents Issuer (CI) 30, and a Rights Issuer (RI) 40.
The CI 30 serving as an entity to provide contents, encrypts contents, for example, as a DRM contents format (DCF), and sends the encrypted contents to the device 10 inside the domain 20.
The RI 40 serves to provide a domain RO about the issued contents.
The operation of the conventional DRM system will be explained with reference to FIGS. 1 and 2.
Firstly, the devices 11˜14 send a message requesting to join a domain (e.g., Join Domain Request message) to the RI 40 (S11).
The RI 40 creates a domain key about the domain 20 (S12).
Then, in response to the request, the RI 40 sends the generated domain key to the devices 11˜14, with including in a message responding with respect to join a domain (e.g., Join Domain Response message) (S13).
Referring to FIG. 1, the RI 40 sends a domain RO to any device among the devices 11˜14, e.g., the first device 11.
The CI 30 provides encrypted contents, to any device among the devices 11˜14, e.g., the first device 11.
Once said any device, e.g., the first device 11 receives the contents and the RO, the first device 11 sends the received contents and RO to the second to fourth devices (12˜14) for sharing. Here, the first to fourth devices (11˜14) may share ROs issued from different RIs.
Once the contents and the RO are received, the first to fourth devices (11˜14) decode the RO by using the domain key, and then consume the contents according to Permission and/or Constraint included in the RO.
Here, if the fourth device 14 inside the domain 20 is mal-operated, or is hacked by a malicious user, the contents may leak out or may be illegally used. When the contents have a possibility to be illegally consumed, the domain can be upgraded.
A process for upgrading the domain will be explained as follows.
Firstly, the RI 40 updates a domain key (S14). Then, the RI 40 sends a message inducing to join a domain (e.g., DMP Join Domain Trigger message) to other devices 11˜13 rather than the fourth device 14 (S15). In response to the reception, the other devices 11˜13 sends a message requesting to join a domain (e.g., Join Domain Request message), to the RI 40 (S16). The RI 40 sends the updated domain key to the other devices 11˜13, with including in a message responding with respect to join a domain (e.g., DMP Join Domain Response message) (S17).
The RI 40 updates the RO, and sends the updated RO to the other devices 11˜13.
After the domain 20 has been upgraded, if a new device requests the domain 20 to join the domain 20, the RI 40 provides, to the new device, not only the updated domain key and domain RO, but also the domain RO and the domain key before upgrade, so that the new device can consume not only contents after upgrade but also contents before upgrade.
However, if the new device is mal-operated, or is hacked by a malicious user after upgrade, the contents before upgrade may leak out or may be illegally used, since the new device has been provided with both the domain RO and the domain key before upgrade.
FIG. 3 is an exemplary view showing domain members, and domain keys issued to the domain members according to each domain generation.
Referring to FIG. 3, the horizontal axis represents G0 and G1, respectively indicating first generation (G0) and second generation (G1) of the domain 20. And, the vertical axis represents the first device 11, the second device 12, and the third device 13.
As shown in FIG. 3, the first device 11 and the second device 12 firstly request to join the first generation (G0), and receive, from the RI 40, a domain key of version 1 (DK0) issued thereto (S11˜S13). And, the first device 11 and the second device 12 receive the domain RO of version 1 (RO0), and digital contents of version 1 (DCF0) for sharing.
Here, if it is determined that the second device 12 of the domain member is a malicious device, the RI 40 revokes the second device 12 from the domain 20.
And, the RI 40 upgrades generation of the domain 20 to a second generation from a first generation. And, the RI 40 updates the domain key of version 1 (DK0) into a domain key of version 2 (DK1) (S14), and sends a message inducing to join a domain (e.g., Join Domain Trigger message) to the other device 11 rather than the second device 12 (S15). Once receiving a message requesting to join a domain (e.g., Join Domain Request message) from the first device 11 (S16), the RI 40 sends a message responding with respect to join a domain (e.g., Join Domain Response message), to the first device 11, with including the domain key of version 2 (DK1) therein (S17).
After the domain 20 is upgraded to the second generation (G1) from the first generation (G0) by the RI 40, when the third device 13 requests to join the domain 20, the RI 40 sends, to the third device 13, not only the domain key of version 2 (DK1), but also the domain key of version 1 (DK0). Here, the domain keys are issued through S11, S12 and S14 of FIG. 2. And, the RI 40 sends, to the third device 13, not only RO of version 2 (RO1) but also RO of version 1 (RO0).
Here, the current domain members that belong to the second generation (G1) of the domain 20 are the first device 11 and the third device 13. The first device 11 and the third device 13 share not only digital contents of version 2 (DCF1), but also digital contents of version 1 (DCF0).
Here, if the third device 13 is mal-operated in the second generation (G1) of the domain 20, or is hacked or cracked by a malicious user, the third device 13 may leak out or illegally consume the digital contents of version 2 (DCF1) at the second generation (G1) of the domain 20. Furthermore, since the third device 13 has the domain RO of version 1 (RO1), and the domain key of version 1 (DK0) at the first generation (GO) of the domain 20, the third device 13 may decode the digital contents of version 1 (DCF0) by using the domain RO of version 1 (RO1). Also, the third device 13 may illegally consume, or leak out the digital contents of version 1 (DCF0)
As aforementioned, when members newly participating in a domain are mal-operated, or are hacked or cracked by a malicious user, contents in the domain before upgrade may be illegally used or may leak out, due to the previous domain key and domain RO before upgrade
For domain upgrade, three processes S15˜S17 of FIG. 2 have to be performed, which severely wastes networks. Especially, under a state that members of the domain are implemented in several tens of members in number, if the members simultaneously undergo the processes S15˜S17 of FIG. 2, network resources are very severely wasted.
Furthermore, domain keys are issued through the processes shown in FIG. 2 at the time of domain upgrade, and devices participating in a domain after domain upgrade receive all domain keys of the previous generation. Accordingly, if the devices having joined a domain perform malicious actions, access to a domain RO of the previous generation before the joining is enabled. Accordingly, not only the current Domain contents, but also Domain contents of the previous generation may be illegally consumed in weak security.